Chapter 3: JavaScript Architecture
Understanding JavaScript Architecture can be helpful when you are learning how to code. If you have a good understanding about how JavaScript works online, you are at an advantage.
There are three types of JavaScript architecture. Typical, Framework based and Advanced.
Typical JavaScript Application Architecture
Ordinarily, JavaScript applications use the bottom-up approach. The User Interface is put at the center of development at all times. The User Interface and the server link directly to the code from behind.
This JavaScript architecture is mostly used for simple programs like websites that don’t require intricate frameworks. It simply can’t keep up with more complex programs. It does allow you to interact with the screen, but it just does not have the capacity for a large scale application.
SPAs or Single page applications make use of typical JavaScript Architecture. They can be updated easily and they are still in demand today. SPAs can only be used in a web browser, so they rely a lot on JavaScript. SPAs tend to be faster than mobile apps because the script that was used to build them only needs to be loaded once. From that point on its only job is to send data between the user and the server.
Framework-Based Architecture
As time progressed, The capabilities of Typical application architecture were not able to keep up with the needs of programmers around the world. Thus Framework based Architecture was born. It is able to solve more complex problems because it makes use of either the MVC or the MVVM patterns.
MVC stands for Model View Controller. It splits larger applications into different sections that all have distinct functions. Each section is equipped to handle different aspects of an application. The model represents everything data related. It gets its commands from the controller and then carries out the user’s input. The view controls everything User Interface related. It gets the input from the user and then presents the data from the model to the user. The controller is the connection between the two. It processes and manipulates data from either side and then produces an output.
There are different adaptations of MVC:
HMVC–Which stands for Hierarchical Model view controller. It is essentially the same thing as MVC, but with layers and more capabilities It takes MVC and repeats it in different parts of the application. Having it in layers does wonders for app development. You can easily reuse the code and not have to worry about constant maintenance.
MVA–Which stands for Model View Adapter. Usually data travels from the controller to the model, but with MVA the controller is the go-between and the Model and View must pass it. View and Model do not actually intersect. Here, the Controller acts as an adapter.
MVP–Which stands for Model View Presenter. This one is slightly different from MVC. The presenter is in charge of all the data in the application. It sends that data to the model to process, receives it back and then passes it onto the View.
MVVM–Stands for Model-View ViewModel and is like an amalgamation of MVC and MVP because it borrows from their patterns. Data and information are completely separate from the User Interface. The controller is replaced by the Viewmodel which connects the Model and the View. The Viewmodel updates the Model every time it receives input and then adapts that data before sending it off to the View.
The framework has a feature rich Runtime environment that renders and puts out the Application. We can liken the Runtime environment to a vessel. It consists of all the things we need to run JavaScript code. Namely:
     The Engine
     Web API’s
     Event loops
     Call back queue
     Micro task queue
JavaScript Engines
Engines take the intricate code written in JavaScript and convert it into a code that the machine can understand. Each browser has its own engine. A few notable engines are V8, SpiderMonkey and JavaScript Core.
V8
No two engines are the same, they all run differently but ultimately do the same thing. In the V8 engine, everything starts in the Parser. The Parser checks for syntax and semantics. Syntax is the structure that the code comes in and Semantics refers to what certain words and symbols in the code mean. The parser then analyzes and breaks the code down to make it into Abstract Syntax Tree(AST). AST is the representation of the source code in tree form. The AST then goes into the Interpreter. The Interpreter converts the AST into Byte Code. This is known as ignition. Sometimes code gets repeated up to one thousand times. When this happens, the Profiler checks for the code repetition and tries to optimize it. Once it gets the optimized code, it moves it on to the Compiler. The compiler in the V8 engine is called TurboFan. Turbofan releases the Byte Code in its most optimized form.
SpiderMonkey
SpiderMonkey was actually the first engine and it was created in 1995. The Mozilla foundation has kept it going and still makes use of it today. The engine converts the JavaScript code into ByteCode first and then sends it to the Interpreter and the JIT Compiler. JIT stands for Just in Time. The JIT Compiler optimizes the code and sends any unused code to the Garbage collector.
Web API’s
API stands for Application Programming Interface. It is an interface that gives the User a set of functions, while concealing the underlying mechanism of that function. Web API’s are not actually part of JavaScript. They are located in the browser, but they do give us access to the JavaScript Engine.
Web API’s are comprised of:
     A set timeout–Allows you to execute a block of code after a certain amount of time (defined by you) has passed
     DOM API’s - Are made up of the interfaces that define how each of the elements in HTML function. That includes any supporting types and interfaces they may rely on.
     Fetch–API Gives JavaScript access to manipulate requests and responses in the Call Stack
     Local storage–Lets JavaScript apps save important value pairs indefinitely
     Console–Registers any and all messages logged by JavaScript code
     Location–Allows users of the browser to share their Geographical location at any given time
Event Loops
JavaScript is a single threaded code. This means that it can only run one command at a time. These commands are synchronous because they run one after the other. This doesn’t always work in programming so there are ways to make JavaScript asynchronous. Things like Call stacks help to avoid any blocking that might happen in a synchronous thread.
A Call stack is a mechanism used by the interpreter to keep track of functions and their place in any given script. It allows functions to run concurrently. When the script calls a function, the interpreter puts it in the call stack and then conducts the function.
A Callback Queue is like a safe house where an unexecuted line of script stays until it’s time for it to run.
The Event Loop’s job is to check the Call Stack and Callback Queue. If the Call Stack is empty, Event Loop will take the statement in the Callback Queue and push it to the Call Stack. It appears to be a pretty straightforward process, but there is something called the MicroTask Queue. The MicroTask queue is pretty much a carbon copy of the Callback Queue but it has a higher priority, which means that any functions in it will be executed first.
MPAs or Multi Page applications are better built with Framework based architecture. They are obviously larger than Single Page Applications and take more time to build. Because it’s data heavy, a lot of information has to go back and forth between the browser and the server. This makes it slower than an SPA. Some developers use AJAX to lighten the load, but it’s still not as widely used because it’s simply too much to maintain.
Advanced JavaScript Architecture
Even though Framework Architecture has more capabilities than typical architecture, it still has its limits when it comes to constructing larger applications. The only way it could grow to accommodate larger apps would be through constant maintenance and development. MVC and MVVM patterns are convenient and allow for developers to reuse code, but they present problems in the framework. The User Interface became compromised because the controller was corresponding with the server while manipulating the view. The need for a more feature rich architecture arose, then Advanced JavaScript Architecture came to be. In this architecture the User interface and server correspondence work completely separately, so it is easy to keep up with any demands that larger apps might have.
Data computation and User Interface are completely separate in this instance. The User Interface is no longer at the center, so the app becomes easier to manage and use.
Universal Applications
Formally known as Isomorphic applications, they provide faster browser connection because there is less code. They work on both the client and server side, ensuring much easier engagement and less work for the programmer. The one downside is that they are quite hard to debug.